The present invention relates to data processing systems and methods for processing pixel data, such as pixel format transformations.
Pixel data is stored with varying representations of the data depending upon the device that is used to display the pixel data or the device that is used to acquire the pixel data. The devices used to acquire and to display pixel data typically vary by industry and/or scientific domain. The range of possible uses and the range of devices that use pixel data is very large.
Pixel data is maintained in some format. This format can include a number of components, such as color channels in the pixel data, the depth or number of bits per component, the order of the components, whether the data has a floating decimal point or a fixed decimal point, whether the data is signed or unsigned, etc. An example of a typical pixel data format is pixel data in the RGB format with 8 bits per each of the color components (red, green and blue).
In order for pixel data to be exchanged between devices of different capabilities, pixel data is often transformed to a format that is amenable to the device that operates on it. For example, pixel data in an RGB format with 8 bits per color channel (8/8/8) may need to be transformed to pixel data in a BGR format having 4 bits per channel (4/4/4). The set of possible image transforms is proportional to the square of the number of possible formats (N) less the number of possible formats; in other words, the set of possible image transforms is equal to (N×N)−N. Conservatively speaking, there are 50 commonly used pixel formats and hence there are about 2,450 possible pixel format transforms.
Format transformations are only one common type of pixel processing. Consider that if other types of pixel transformation/modulations are done, it has a multiplying effect on the number of transformation modules that must be maintained. Examples of some common pixel transformation or modulation functions are scale and bias, multiplication by a color matrix, application of a lookup table, color space conversions and many others. Consider the addition of just one of these operations to pixel processing transformation: scaling the pixel values. To create an optimally performing module, without conditional testing (branching), one would need to create a module with scaling enabled and another one without. In this way, one could invoke the module that is tailored to the desired operation (the module with scaling, or the one without). In effect, the result of adding scaling as a feature of a system's pixel format transformation logic has created twice the number of modules to write and maintain. Add three more stages to this pixel processing, such as bias, color matrix, and a lookup table, and the number of branch free modules that would have to be maintained would be multiplied by 5. This combinitoric explosion scenario can be extended ad-infinitum for as many pixel transformations/modulation routines the user may wish to apply.
The logic required to transform and modulate pixels in one format to pixels in another format is different for each possible combination of input and output format and type of modulation. Building and maintaining a dedicated logical module for every possible transform and modulation requires a great deal of time and effort. A common solution which attempts to avoid this problem is to construct a module that iterates over the pixel data, and within each iteration, selects the input format, output format, and modulation logic to perform the transformation. This latter approach requires testing the format and modulation parameters to determine a logical path and then conditionally branching for each pixel processed in the loop. This conditional testing results in a great deal of overhead and stalling on modern computer processors. The first approach, which involves building individual custom transforms, has significantly better performance than the second approach, which includes conditional branching within the pixel data processing loop. However, because of all of the combinitoric state involved, building the individual custom transforms typically requires an enormous effort to develop and maintain this large number of functional modules.